Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Serpent material temps #178

Merged
merged 14 commits into from
Jan 9, 2023
Merged

Conversation

yardasol
Copy link
Contributor

@yardasol yardasol commented Nov 28, 2022

Summary of changes

This PR adds machinery to maintain cross section data consistency between depletion steps when using SaltProc with Serpent2. Previously, the fix card was hardcoded to a library id of 09c, but now SaltProc checks for the fix option which tells Serpent which library IDs to use for a material, and uses the same value for the fix option in the entire simulation.

Specifically, this PR:

  • Adds two functions to SerpentDepcode:
    • get_burnable_materials_file(), a helper function for create_runtime_matfile()
    • get_burnable_material_card_data() that scrapes the template material file and stores the material cards in an attribute

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Required for Merging

  • I have read the CONTRIBUTING document.
  • My code follows the code style of this project.
  • My change requires a change to the documentation.
    • I have updated the documentation accordingly.
  • My change is a source code change
    • I have added/modified tests to cover my changes
    • I have explained why my change does not require new/modified tests
  • My change is a user-facing change
    • I have recorded my changes in the changelog for the upcoming release
  • My change is exclusively related to the repository (e.g. GitHub actions workflows, PR/issue templates, etc.)
    • I have verified or justified that my change will work as intended.
  • All new and existing tests passed.
    • CI tests pass
    • Local tests pass (including Serpent2 integration tests)

Associated Issues and PRs

Associated Developers

  • Dev: @

Checklist for Reviewers

Reviewers should use this link to get to the
Review Checklist before they begin their review.

@yardasol yardasol force-pushed the serpent-material-temps branch from 35101a0 to 32c02be Compare November 28, 2022 18:44
@yardasol yardasol mentioned this pull request Nov 29, 2022
17 tasks
@yardasol yardasol force-pushed the serpent-material-temps branch 2 times, most recently from ebf2dc4 to 5f84d01 Compare December 6, 2022 17:24
@yardasol yardasol marked this pull request as ready for review December 7, 2022 17:40
Copy link
Contributor

@abachma2 abachma2 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @yardasol. This looks good overall. I have a few questions to be answered. For your integration tests, it looks like you've only added one test, but your function changes include if loops. Do you think you need tests to cover what happens in the if loops?

shutil.copy2(absolute_path, self.runtime_matfile)
return [line.replace(burnable_materials_path, self.runtime_matfile) for line in file_lines]

def get_burnable_materials_file(self, file_lines):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you need a docstring for this function?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is a private function, I will accept not having a docstring. Since users should never interact with it. In this case, the code is documentation. However, if it is a private function it should have a single underscore at the beginning of the method name.

# Create file with path for SaltProc rewritable iterative material file
shutil.copy2(absolute_path, self.runtime_matfile)
return [line.replace(burnable_materials_path, self.runtime_matfile) for line in file_lines]
def get_burnable_material_card_data(self, file_lines):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you need a docstring for this function?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment as above.

mat.vol))
mat_card, card_volume_idx = self.burnable_material_card_data[name]
mat_card[2] = str(-mat.density)
mat_card[card_volume_idx] = "%7.5E" % mat.vol
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feels like a hardcoded value. Is this the case?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No this is string formatting

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's what I was thinking. Just wanted to make sure it wasn't hard coding any values.

Copy link
Contributor

@samgdotson samgdotson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems fine, just answer @abachma2's questions.

shutil.copy2(absolute_path, self.runtime_matfile)
return [line.replace(burnable_materials_path, self.runtime_matfile) for line in file_lines]

def get_burnable_materials_file(self, file_lines):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is a private function, I will accept not having a docstring. Since users should never interact with it. In this case, the code is documentation. However, if it is a private function it should have a single underscore at the beginning of the method name.

# Create file with path for SaltProc rewritable iterative material file
shutil.copy2(absolute_path, self.runtime_matfile)
return [line.replace(burnable_materials_path, self.runtime_matfile) for line in file_lines]
def get_burnable_material_card_data(self, file_lines):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment as above.

@yardasol
Copy link
Contributor Author

yardasol commented Dec 7, 2022

@abachma2

For your integration tests, it looks like you've only added one test, but your function changes include if loops. Do you think you need tests to cover what happens in the if loops?

You are correct, I absolutely should.

Copy link
Contributor

@abachma2 abachma2 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for making these latest changes @yardasol. I have one other comment about the tests. Once you write more tests to cover the if loops in your functions I will approve and merge this PR.

@@ -36,6 +36,54 @@ def test_runtime_input_from_template(serpent_depcode, msr):
file_data = serpent_depcode.create_runtime_matfile(file_data)
assert file_data[0].split()[-1] == '\"' + \
serpent_depcode.runtime_matfile + '\"'

# get_burnable_material_card_data
_burnable_material_card_data = {'fuel':
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this is just a knowledge gap on my part, but why did you add the underscore here? This looks like a variable to me, not a call of that private function?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a private attribute

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I get that for in line 79. But even when you define it here and use it in line 80? It's still a private attribute in those locations?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no, this is just for naming consistency. Should I name it something else?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would recommend changing the same some when you're not calling the attribute. It was a little confusing to me to have the two things you're comparing be named the same thing. I like to use the exp and obs (as in expected and observed) that Katy uses in her book for my tests. But your choice as to what you change it to.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay I'll do this

Copy link
Contributor

@abachma2 abachma2 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for adding the unit tests @yardasol. I think they make the test suite more robust. It looks like your unit tests are just testing that the proper error is raised. Do you also have a test in there for when the inputs have the correct information and the function should execute as expected?

@@ -36,6 +36,54 @@ def test_runtime_input_from_template(serpent_depcode, msr):
file_data = serpent_depcode.create_runtime_matfile(file_data)
assert file_data[0].split()[-1] == '\"' + \
serpent_depcode.runtime_matfile + '\"'

# get_burnable_material_card_data
_burnable_material_card_data = {'fuel':
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I get that for in line 79. But even when you define it here and use it in line 80? It's still a private attribute in those locations?

@yardasol
Copy link
Contributor Author

yardasol commented Dec 7, 2022

Do you also have a test in there for when the inputs have the correct information and the function should execute as expected?

Yes, that machinery is added to the integration test test_file_interface_serpent

@abachma2
Copy link
Contributor

abachma2 commented Dec 7, 2022

Do you also have a test in there for when the inputs have the correct information and the function should execute as expected?

Yes, that machinery is added to the integration test test_file_interface_serpent

And you think that having that only in an integration test is sufficient? It doesn't need its own unit test? I'm not expecting a certain answer, I'm genuinely asking.

@yardasol
Copy link
Contributor Author

yardasol commented Dec 7, 2022

And you think that having that only in an integration test is sufficient? It doesn't need its own unit test?

It should be sufficient. As long as the user provides correct input paths none of the errors should be raised, and the code will run correctly. Maybe @munkm can chime in?

@yardasol
Copy link
Contributor Author

yardasol commented Dec 9, 2022

@samgdotson bump

@munkm
Copy link
Member

munkm commented Dec 15, 2022

ok @yardasol and @abachma2 I took a look. I think generally the integration test is probably good enough for this case. However, having a unit test that checks the specific function like Amanda brought up would be even better. Users are good at generating all sorts of weird corner cases and this integration test isn't going to capture that (or any improvements to the tooling that detects the input paths). Are errors raised consistently for all sorts of weird iterations of paths (I don't see that tested here)? Are the expected errors raised? If a user comes up with a case where they enter a path wrong and the error isn't raised, where would they modify this integration test to include it? I don't see an obvious spot in test_file_interface_serpent. I don't see an assertion that an error is raised with a wrong configuration either. Am I missing it?

@yardasol
Copy link
Contributor Author

@munkm

Are errors raised consistently for all sorts of weird iterations of paths (I don't see that tested here)?

If a path is bad, Python should raise a FileNotFoundError. My personal opinion is that it is out-of-scope to try to test fundamental Python machinery in a program built on top of it.

Are the expected errors raised?

See this test.

If a user comes up with a case where they enter a path wrong and the error isn't raised, where would they modify this integration test to include it?

Again, this is more of an issue with python itself than it is with SaltProc.

I don't see an assertion that an error is raised with a wrong configuration either. Am I missing it?

I'm not sure what you mean by this. Are you talking about the return message? Or are you talking about assertions than a particular error is raised? If the latter, see the above link.

@yardasol
Copy link
Contributor Author

yardasol commented Jan 2, 2023

@munkm bump

Copy link
Contributor

@samgdotson samgdotson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems fine, apologies for the delay.

@samgdotson samgdotson merged commit beb9b1d into arfc:master Jan 9, 2023
github-actions bot pushed a commit that referenced this pull request Jan 9, 2023
github-actions bot pushed a commit to khurrumsaleem/saltproc that referenced this pull request Jan 10, 2023
@munkm
Copy link
Member

munkm commented Jan 11, 2023

I'm good with this merge now that there's an open issue! Thanks for doing that @samgdotson

@munkm
Copy link
Member

munkm commented Jan 11, 2023

But please next time check with the other people who have started review before merging. It wasn't clear if @abachma2 had approved yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Bug]: Fuel Material Temperature Hardcoded (maybe?) in saltproc_mat
4 participants